home *** CD-ROM | disk | FTP | other *** search
/ Languguage OS 2 / Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO / language / embedded / mcu332 / 332doc.arc / 332BUGC& < prev    next >
Text File  |  1989-12-19  |  10KB  |  240 lines
  1.                                                                       
  2.   DEBUG MONITOR USER'S MANUAL    MOTOROLA
  3.   1-1     M68332BUG
  4.  
  5.                                                                       
  6.   DEBUG MONITOR USER'S MANUAL    MOTOROLA
  7.   M68332BUG    1-1
  8.  
  9.  
  10. CHAPTER 1
  11.  
  12. GENERAL INFORMATION
  13.  
  14.  
  15.  
  16. 1.1  INTRODUCTION
  17.  
  18. This chapter provides a general description, installation instructions, start-up and system 
  19. restart instructions, memory requirements, and a terminal input/output (I/O) control description 
  20. for the M68332BUG Debug Monitor (hereafter referred to as 332Bug).  Information in this 
  21. manual covers the 1.01 version of the 332Bug.
  22.  
  23. 1.2  GENERAL DESCRIPTION
  24.  
  25. The 332Bug package evaluates and debugs systems built around the M68332BCC Business 
  26. Card Computer.  System evaluation facilities are available for loading and executing user 
  27. programs.  Various 332Bug routines that handle I/O, data conversion, and string functions are 
  28. available to user programs through the TRAP #15 handler.
  29.  
  30. 332Bug includes:
  31.  
  32. Ñ    Commands for display and modification of memory,
  33. Ñ    Breakpoint capabilities,
  34. Ñ    A assembler/disassembler useful for patching programs,
  35. Ñ    A power-up self test feature which verifies system integrity,
  36. Ñ    A command-driven user-interactive software debugger (the debugger), and 
  37. Ñ    A user interface which accepts commands from the system console terminal.
  38.  
  39.  
  40. There are two modes of operation in the 332Bug monitor; the debugger mode and the 
  41. diagnostic mode.  When the user is in the debugger directory the prompt 332Bug> is 
  42. displayed, and the user has access to the debugger commands (see Chapter 3).  When the 
  43. user is in the diagnostic mode the prompt 332Diag> is displayed, and the user has access 
  44. to the diagnostic commands (see Chapter 6).  These modes are also called directories.
  45.  
  46. 332Bug is command-driven.  It performs various operations in response to user commands 
  47. entered at the keyboard.  Figure 1-1 illustrates the flow of control in 332Bug.  332Bug 
  48. executes entered commands and the prompt reappears upon completion.  However, if a 
  49. command is entered which causes execution of user target code (i.e., GO) then control may 
  50. or may not return to 332Bug.  This depends upon the user program function.
  51.  
  52. 332Bug is similar to Motorola's other debugging packages, but there are two noticeable 
  53. differences.  Many of the commands are more flexible with enhanced functionality.  And the 
  54. debugger has more detailed error messages and an expanded on-line help facility.
  55.  
  56.  
  57.  
  58.                                                                    
  59.  
  60.  
  61.  
  62. Figure 1-1.  332Bug Operation Mode Flow Diagram
  63.  
  64. 1.3  USING THIS MANUAL
  65.  
  66. Those users unfamiliar with debugging packages should read Chapter 1 before attempting to 
  67. use 332Bug.  This provides information about 332Bug structure and capabilities.
  68.  
  69. Paragraph 1.4 INSTALLATION AND START-UP describes a step-by-step procedure for 
  70. powering up the module and obtaining the 332Bug prompt on the terminal screen.
  71.  
  72. For questions about syntax or operation of a particular 332Bug command, turn to the 
  73. paragraph which describes that particular command in Chapter 3.
  74.  
  75. Some debugger commands take advantage of the built-in one-line assembler/disassembler.  
  76. The command descriptions in Chapter 3 assume that the user is familiar with the 
  77. assembler/disassembler functionality.  Chapter 4 includes a description of the assembler/ 
  78. disassembler.
  79.  
  80. NOTE
  81.  
  82. In the examples shown, all user inputs are given in bold text.  This should clarify 
  83. the examples by distinguishing between character input by the user and 
  84. character output by 332Bug.  The symbol <CR> represents the carriage return 
  85. key on the user's terminal keyboard.  Whenever this symbol appears it indicates 
  86. a carriage return should be entered by the user.
  87.  
  88.  
  89. 1.4  INSTALLATION AND START-UP
  90.  
  91. Use the following set-up procedure to enable 332Bug to operate with the M68332BCC:
  92.  
  93.     a.    Configure the jumpers on the BCC module.  Refer to the M68332BCC User's 
  94. Manual Motorola publication number M68332BCC/AD1
  95.  
  96.     b.    Connect the DB-9 serial communication cable connector to the terminal or 
  97. host computer which is to be the 332Bug system console.  Connect the other 
  98. end of the cable to P4 on the BCC.
  99.  
  100. Set up the terminal as follows:
  101. Ñ    Eight bits per character
  102. Ñ    One stop bit per character
  103. Ñ    Parity disable
  104. Ñ    9600 baud rate
  105.  
  106.  
  107. NOTE
  108.  
  109. In order for high-baud rate serial communication between 332Bug 
  110. and the terminal to function properly, the terminal must use 
  111. XON/XOFF handshaking.  If messages are garbled and have 
  112. missing characters, check the terminal to verify XON/XOFF 
  113. handshaking is enabled.
  114.  
  115.     c.    Power up the system.  332Bug executes a self-test and displays the sign on 
  116. message (which includes version number) and the debugger prompt 332Bug>.
  117.  
  118. 1.5  SYSTEM RESTART
  119.  
  120. There are three ways to initialize the system to a known state.  Each situation determines the  
  121. appropriate system restart technique.
  122.  
  123. 1.5.1  Reset
  124.  
  125. The M68332PFB platform board reset pushbutton returns the system to a known state.  When 
  126. the reset pushbutton is first pushed the MC68332 MCU send the default XON character to the 
  127. terminal to prevent possible terminal lockup.  There are two reset modes:  COLD and WARM.  
  128. COLD reset mode is the 332Bug default, refer to the RESET command description.  During 
  129. COLD reset a total system initialization occurs, similiar to the M68332BCC power-up 
  130. sequence.  All static variables are restored to their default states.  The serial port is reset to its 
  131. default state.  The breakpoint table is cleared. The offset registers are cleared.  The target 
  132. registers are invalidated.  Input and output character queues are cleared. On-board devices 
  133. (timer, serial ports, etc) are reset.  During WARM reset, 332Bug variables and tables are 
  134. preserved, as well as the target state registers and breakpoints.
  135.  
  136. Use reset if the processor halts, for example, after a halt monitor fault, or if the 332Bug 
  137. environment is lost (vector table is destroyed, etc).
  138.  
  139. 1.5.2  Abort
  140.  
  141. The M68332PFB platform board ABORT pushbutton terminates all inprocess instructions.  
  142. When abort is executed while running target code, a snapshot of the processor state is 
  143. captured and stored in the target registers.  For this reason Abort is appropriate when 
  144. terminating a user program that is being debugged.  Use abort to regain control if the 
  145. program gets caught in a loop, etc.  The target PC, stack pointers, etc. help pinpoint 
  146. malfunctions.
  147.  
  148. Abort generates a non-maskable, level-seven interrupt. The target registers reflect the 
  149. machine state at the time of an abort and are displayed on the display screen.  Any 
  150. breakpoints installed in the user code are removed and the breakpoint table remains intact.  
  151. Control is then returned to the debugger.
  152.  
  153. 1.5.3  Break
  154.  
  155. The BREAK key on the terminal keyboard initiates a break.  Break does not generate an 
  156. interrupt.  The only time break is recognized is when characters are sent or received by the 
  157. debugger console. Break removes any breakpoints in the user code and keeps the 
  158. breakpoint table intact.  Break does not, however, take a snapshot of the machine state nor 
  159. does it display the target registers.  It is useful for terminating active debugger commands that 
  160. are outputing large blocks of data.
  161.  
  162. NOTE
  163.  
  164. When using terminal emulation programs such as ProComm or Kermit, the 
  165. BREAK key on the keyboard is local to the emulation program and may not be 
  166. transmitted to the BCC.  Consult your emulation program's user manual for the 
  167. procedure on sending a BREAK signal to the port connected to the BCC.
  168.  
  169.  
  170.  
  171.  
  172. 1.6  MEMORY REQUIREMENTS
  173.  
  174. The program portion of 332Bug is approximately 64k bytes of code. The EPROM on-board 
  175. the M68332BCC contains 128k bytes and is mapped at locations $60000 to $7FFFF.  
  176. However, the 332Bug code is position-independent and can execute anywhere in memory.  
  177. The second half of the EPROM ($70000 - $7FFFF) is blank and available for user programs.  
  178. See Appendix C 332Bug Customization.
  179.  
  180. 332Bug requires a minimum of 12k bytes of random access memory (RAM) to operate.  This 
  181. memory may be either off-board system memory (i.e., on an external memory board) or 
  182. M68332BCC on-board RAM.  On-board RAM allows stand-alone operation of the 
  183. M68332BCC.
  184.  
  185. The first 12k bytes are used for 332Bug stack and static variable space and the rest of 
  186. memory is reserved as user space.  Whenever the M68332BCC is reset, the target program 
  187. counter is initialized to the beginning user space address and the target stack pointers are 
  188. initialized to addresses at the end of the user space.  The target instruction stack pointer 
  189. (SSP) is set to the top of the user space.  Register initialization is done solely as a 
  190. convienience for the user.  Consult the CPU32 Reference Manual for information regarding 
  191. actual register values during a power-on/reset.
  192.  
  193.  
  194.  
  195.  
  196.                                                                
  197.  
  198.  
  199.  
  200.  
  201. Figure 1-2.  BCC Memory Map
  202.  
  203. 1.7  TERMINAL INPUT/OUTPUT CONTROL
  204.  
  205. When entering a command at the prompt, the following control codes may have a caret, " ^ ", 
  206. preceding the character, this indicates that the Control or CTRL key must be held down while 
  207. striking the character key).
  208.  
  209.     ^X (Cancel line)    -    The cursor is backspaced to the beginning of the line.  
  210. If the terminal port is configured with the hardcopy or 
  211. TTY option (see PF command) then a carriage return, 
  212. line feed, and new prompt are displayed.
  213.  
  214.     ^H (backspace)    -    The cursor is moved back one position.  The character 
  215. at the new cursor position is erased.  If the hardcopy 
  216. option is selected a slash (/) character is typed along 
  217. with the deleted character.
  218.  
  219.     <del> (delete/rubout)    -    Performs the same function as ''^H''.
  220.  
  221.     ^D (redisplay)    -    The entire command line as entered is redisplayed on 
  222. the following line.
  223.  
  224. When observing output from any 332Bug command, the XON and XOFF characters may be 
  225. entered to control the output, if the XON/XOFF protocol is enabled (default).  These 
  226. characters are initialized to ''^S'' and ''^Q'' respectively by 332Bug, but may be changed by 
  227. the user using the PF command.  The initialized (default) mode operations are:
  228.  
  229.     ^S (wait)    -    Console output is halted.
  230.  
  231.     ^Q (resume)    -    Console output is resumed.
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.